昨天我們確定了專案目標、選定了名字 BoltHQ、規劃了六天的開發計畫。今天要進入最關鍵的階段：寫 PRD 和技術規劃。

這兩個文件決定了整個專案的成敗。寫得好，後面開發就像高速公路；寫得不好，就會不斷返工、改需求、吵架。

但今天不一樣。我要用 AI-DLC Sprint 的方法，讓 AI 成為我的 Product Manager 和 Technical Architect。

AI-DLC Sprint 的 PRD 新思維

還記得我在主系列 Day 18 分享的嗎？AI-DLC Sprint 的 PRD 是：

1. AI 的溝通語言 - 不只是給人看，更是給 AI 看的
2. 活的知識載體 - 隨著專案演進不斷更新
3. 自動化的起點 - 可以自動產生 User Stories、測試案例

所以今天的 PRD，不是傳統的「寫完就丟」文件，而是整個專案的知識中樞。

為什麼 PRD 這麼重要？

很多人（包括以前的我）都覺得 PRD 是個麻煩東西，寫了也沒人看，最後變成 Word 檔案資料夾裡的裝飾品。

但在 AI-DLC Sprint 中，PRD 的角色完全不同：

• 傳統 PRD：寫給人看的，落落長，沒人想讀
• AI-DLC Sprint 的 PRD：寫給 AI 看的，結構化，可執行

這份 PRD 會是接下來 5 天的「聖經」，所有的 User Story、AC、UI 設計、程式碼實作，都會從這份文件衍生出來。

讓 AI PM 來採訪我

昨天我們已經跟 AI 討論過需求了，今天要做的是把那些對話「結晶化」成一份正式的 PRD。

我的做法：用 Claude Subagent

我用 Claude Code 的 Subagent 功能創造一個「PRD 撰寫專家」：

你是一位資深的 Product Manager，專門設計 B2B SaaS 產品。

讀取 [spec.md](http://spec.md)（昨天釐清的需求），產出一份完整的 PRD。

PRD 必須包含：
1. 用戶場景分析
2. 功能優先級（P0/P1/P2）
3. MVP 範圍定義
4. 成功指標
5. 技術適配性分析

請用繁體中文產出，並寫入 docs/[PRD.md](http://PRD.md)

背景資訊（來自昨天的需求釐清）

目標用戶：

1. 三人以內的小團隊（Startup、Side Project）
2. 獨立開發者（Solo Developer）
3. 創新團隊的 Tech Lead

核心痛點：

1. 每個專案都要重新寫 PRD、拆 Story、建 Repo（重複勞動）
2. PRD 在 Notion、Stories 在 Jira、Code 在 GitHub（知識散落）
3. 團隊成員用不同 AI 工具，沒有共同 Context（協作混亂）

MVP 功能（6天內完成）：

1. Spec Input：自然語言 → AI 提問釐清 → 生成 PRD
2. Story Generation：PRD → 自動拆解 User Stories
3. GitHub Sync：自動建 Org Repo、同步文件
4. Basic AI Agents：PM、BA、Architect 三個角色

未來擴展：

• 更多 AI Agent 角色（Designer、QA、Developer）
• 模板庫與最佳實踐
• 即時協作功能
• 知識累積引擎

AI 生成的 PRD 亮

我不會把完整的 PRD 貼在這裡（太長了），但分享幾個 AI 生成的亮點：

具體的用戶畫像

AI 不只是列出 3 個用戶，還給了每個用戶具體的：

• 使用場景：「週末 48 小時 MVP 開發」
• 痛點描述：「時間有限，一人身兼多職」
• 期望結果：「3 天內從想法到上線」

這讓我後續設計功能時，有很清晰的參考對象。

清晰的功能優先級

AI 把功能分成 P0/P1/P2，還給了每個功能的預計工時：

P0 功能（必做，Day 1-4）

• Spec Input 流程 - 8 小時
• PRD 生成引擎 - 6 小時
• User Story 拆解 - 8 小時
• GitHub 基礎整合 - 10 小時

P1 功能（次要，Day 5-6）

• AI Agent 系統 - 8 小時
• 專案管理介面 - 6 小時

P2 功能（未來）

• 模板庫
• 知識累積
• 團隊協作

這讓我很清楚知道，6 天只要專注做 P0 功能就好。

可量化的成功指標

AI 把成功指標分成三類：

功能完整性：

• [ ] 用戶能成功輸入需求並生成 PRD
• [ ] PRD 能自動拆解成 User Stories
• [ ] Stories 能同步到 GitHub Issues

使用體驗：

• PRD 生成時間 < 30 秒
• Story 拆解時間 < 15 秒
• GitHub 同步時間 < 5 秒

技術指標：

• 測試覆蓋率 > 70%
• 頁面載入時間 < 3 秒
• API 回應時間 < 100ms

這些指標讓我在開發時有明確的目標，不會走偏。

明確的「不做清單」

AI 特別列出了「這次不做」的功能：

本次 MVP 不包含：

• 團隊即時協作功能
• 複雜的權限管理
• 自訂 AI Agent 訓練
• 多語言支援
• 行動版 App

這很重要！明確列出不做的功能，可以避免 scope creep（範圍蔓延）。

技術初步規劃

在開始寫 code 之前，我需要先了解：

• 要用什麼技術棧？
• 這些技術能不能滿足我的需求？
• 有沒有什麼潛在風險？

以前的我會去看一堆文件、翻 Stack Overflow、找教學影片，花掉半天時間。

但現在有 Context7，可以直接查最新的官方文件，而且是 AI 可以理解的格式。

用 Context7 查詢技術文件

我讓 AI Architect 查詢了：

• Next.js 14 的最新 Best Practices
• Supabase 的 Real-time 功能
• Anthropic Claude API 的最新限制
• Octokit 的 GitHub API 用法

為什麼用 Context7？

• 確保 AI 不會幻覺（查最新官方文件）
• 避免過時的技術方案
• 直接獲取可執行的程式碼範例

最終確認的技術棧

經過 Context7 的查詢和跟 AI 的討論，我確認了最終的技術棧：

前端框架

• Next.js 14 (App Router)
• TypeScript
• Tailwind CSS + shadcn/ui

狀態管理

• React Query（Server State）
• Zustand（Client State）

後端服務

• Next.js API Routes
• Supabase（PostgreSQL + Auth）

AI 整合

• Anthropic Claude API (Sonnet 4.5)
• Prompt Chaining 架構

GitHub 整合

• Octokit（官方 SDK）
• GitHub OAuth

測試框架

• Vitest（單元測試）
• Playwright（E2E 測試）

資料庫設計（初步）

核心 Tables：

• projects - 專案主表
• prds - PRD 文件（支援版本控制）
• user_stories - User Stories
• ai_agents - AI Agent 定義
• conversations - 對話記錄

這部分只是初步規劃，到了開發階段還會再與 AI 架構師進行更深入的架構規劃。

今天完成了什麼？

• 完整的 PRD 文件（已寫入 docs/PRD.md）
• 清晰的功能優先級（P0/P1/P2 分類）
• 可量化的成功指標（功能、體驗、技術三個維度）
• 技術棧確認（基於 Context7 查詢的最新文件）
• 資料庫初步設計（5 個核心 Tables）

明天預告

今天完成了 PRD 和技術初步規劃，明天（Day 3）要進入 User Story & AC 階段：

明天的任務：

1. 讓 AI BA 從 PRD 自動拆解 User Stories
2. 為每個 Story 定義 Acceptance Criteria
3. 用 INVEST 原則檢查 Story 品質
4. 估算 Story Points
5. 建立 Sprint Backlog

目標是讓明天結束時，Day 4 就能直接開始寫 code。